1. Field of the Invention
The present invention relates to a method for controlling Voice Call Continuity (VCC) related functions in a VCC operation initiated by a terminal by employing VCC capability information and/or VCC enabling information. The invention also relates to the terminal and network server for implementing the method.
2. Description of the Background Art
In general, a Voice Call Continuity (VCC) refers to a service for allowing a call path exchange of voice calls between a 3GPP Circuit Switching (CS) system (e.g., GSM, UMTS, etc.) and an IP Multimedia Subsystem (IMS). That is, the VCC refers to a type of application, namely, a home IMS application which is capable of transporting voice calls between the CS domain and the IMS domain. As such, the VCC provides functions of voice call originations, voice call terminations and a domain transfer from the CS domain to the IMS domain or vice versa. Here, the domain transfer refers to transferring access legs for voice calls toward a User Equipment (UE) (i.e., a terminal) from the CS domain to the IMS domain or vice versa during an active session. The access leg denotes a call control leg between a VCC UE and a Domain Transfer Function (DTF) of the VCC application (server).
Through the domain transfer procedures of the VCC service, continuity for one or more voice sessions is provided between the IMS domain and CS domain while the VCC UE performs the one or more voice sessions. That is, the VCC services provides continuity to the voice call by switching from the IMS domain to the CS domain or vice versa, e.g., when the current domain for the call is not suitable or desired.
According to the VCC service, generally the domain transfer for a certain voice call/session from the CS domain to the IMS domain or vice versa is initiated only when a DTF is positioned (located) on a signal path of the voice call/session setup. For this, positioning of the DTF on the way of the signal path of the voice call/session setup is referred to as anchoring in IMS or anchoring.
FIG. 1 illustrates an architecture of a network for providing a VCC service.
As illustrated in FIG. 1, a VCC UE 10 denotes all types of terminals which can support the VCC service. The VCC UE can access the CS and PS (packet switched) domains. That is, when accessing the CS domain, the VCC UE uses a UE-CS (not shown) provided therein, whereas the VCC UE uses a UE-IMS (not shown) provided therein when accessing the PS domain.
A VCC application 30 is an application server (network server) for providing the VCC service, and is constituted with entities which perform a series of functions. For instance, the series of functions may include functions required to setup voice calls toward the VCC UE, and functions required to switch an access leg of the VCC UE between the CS domain and the IMS domain with maintaining (performing) an active session. Here, the series of functions can be a Domain Transfer Function 30a, a Domain Selection Function (30d), a CS Adaptation Function 30b, and a CAMEL Service Application 30c. Detailed capabilities and operations for the series of functions are described in 3GPP TS 23.206 V1.2.0.
Generally, the CS domain entities include a Visited Mobile Switching Center (VMSC), a Gateway MSC (GMSC), a gsmSCF, and the like. The IMS domain entities include a P-CSCF (Proxy Call Session Control Function) 12, a S-CSCF (Serving Call Session Control Function) 20, a I-CSCF (Interrogating Call Session Control Function) 14, a Media Gateway Control Function (MGCF) 16, and a Home Subscriber Server (HSS) 40.
In order for the VCC UE to receive the VCC services, a registration procedure to the CS and IMS domains must previously be performed. According to the related art VCC technology, the CS registration and IMS registration which are associated with the VCC are as follows.
Specifically, a registration (or an attachment) to the CS domain is performed as the same as an existing registration to the CS domain. The registration to the IMS domain can be performed by the VCC UE only when an IP connectivity is available. The successive registration procedures are performed depending on a subscriber's iFC (initial Filter Criteria). The iFC refers to filter criteria which are a type of user information stored in the HSS. For a VCC subscriber, a third party registration is may occur at the VCC Application Server (VCC AS) 30 depending on the iFC.
FIG. 2 is a signal flowchart illustrating a procedure where a VCC UE registers in an IMS domain according to the background art.
As illustrated in FIG. 2, a VCC UE 10 sends a REGISTER message to a S-CSCF 20 to initiate (start) a registration procedure for a VCC service (S21).
Then the S-CSCF 20 sends information related to a user of the VCC UE 10 to a HSS 40, thereby requesting subscriber information (represented as ‘Cx-Put/Cx-Pull’ in FIG. 2) (S22). The S-CSCF 20 then receives the subscriber information from the HSS 40 (indicated as ‘Cx-Put/Cx-Pull Resp’ in FIG. 2) (S23). The S-CSCF 20 then performs a service logic based upon the iFC included in the received subscriber information and determines if the VCC UE 10 should be registered (S24). If the determination indicates that the registration is allowed (e.g., because the user of the UE 10 is a VCC service subscriber), the S-CSCF 20 performs a third party registration procedure with the VCC AS 30 so as to register the VCC UE 10 at the VCC AS 30 (S25). The VCC AS 30 delivers a 200 OK message to the VCC UE 10 via the S-CSCF 20 after the third party registration procedure is successfully performed (S26 and S27). On the other hand, if the determination at step S24 indicates that the registration is not allowed, then the third party registration procedure is not performed.
Once the VCC UE 10 completes the registration for the VCC service through steps S21 to S27, the network may adapt the following logic for calls associated with the VCC subscriber (i.e., the user of the VCC UE 10).                1) Call origination: when the corresponding VCC subscriber originates a call (i.e., when the call is an outgoing call), an anchoring in the IMS domain is performed for the VCC.        2) Call termination: when a network receives a call which the corresponding VCC subscriber terminates (i.e., when the call is an incoming call directed to the terminal), an anchoring in the IMS domain is performed for the VCC. The CS domain or IMS domain is selected (i.e., a domain selection is performed) and the call is terminated in the selected domain.        3) Domain selection: the corresponding VCC subscriber (i.e., the VCC UE user) selects a currently activated domain or the most suitable domain based upon operator policy.        4) Domain transfer: domain transfer for an ongoing call is initiated from a first domain to a second domain.        
In the VCC service according to the background art, the network manages the VCC service subscription information of the users, but the network does not and can not know whether a terminal communicating with the network server is a VCC capable UE or not. Such technical limitation causes a waste of resources due to unnecessarily initiating or attempting to perform VCC related operations between the terminal and the network even though the terminal does not have the VCC capability.
In particular, in a first case where the terminal user has a VCC subscription and the terminal is a VCC non-capable terminal (i.e., terminal does not have the VCC capability), and in a second case where the terminal user has no VCC subscription and the terminal used by the user is a VCC capable terminal (i.e., terminal has the VCC capability), the waste of resources may be caused in the VCC service system according to the background art by initiating or performing the VCC-related operations.
For example, in the first case according to the background art, when the terminal user has the VCC subscription but uses a terminal which can not support the VCC (i.e., VCC non-capable UE), the network still performs or initiates the VCC-related operations (or functions) in communication with the corresponding terminal, which results in a consumption of resources since the terminal cannot support the VCC-related operations. Also, to perform the needless VCC-related operations according to the background art, extra signaling and radio resources are used for no reason, the terminal's battery life is shortened, and the terminal's CPU power is also degraded.
Furthermore, even if the user has the VCC subscription and uses the VCC capable terminal (UE), after registering to the network, the VCC function of the VCC capable terminal can be enabled or disabled, depending on the user's various circumstances (e.g., user's preferences) and communication conditions. For example, if the VCC function at the terminal is set as enabled, the domain transfer for an ongoing call (i.e., incoming call or outgoing call) may be performed. However, in this case, if the terminal is currently located (positioned) in the overlapped coverage area between the CS and a IP-CAN (IP-Capable Access Network), unnecessary domain transfers may frequently occur or a communication inconsistency can severely occur during the domain transfer performed. In this case, in order to address this problem, the user may desire to disable the VCC capability of his terminal temporarily. As such, there is a need for a technique of changing (controlling), depending on the user's preferences, the VCC function from being enabled to being disabled or vice versa under the control of the terminal, and communicating this changed information to the VCC application so that the VCC application does not waste resources in initiating unnecessary VCC operations.